1. Field of the Invention
This invention relates to improvements in computer systems and methods, and more particularly to improvements in computer systems and methods for interfacing server and client computers and for installing computer software and software applications.
2. Relevant Information
In the past, software manufacturers have distributed software products for installation on computer systems on one or more floppy disks. However, as computer programs have become more and more complicated, a greater number of floppy disks have been required to contain the entire software product. As a result, as many software products have reached a size of 800 megabytes or more, the former floppy disk distribution methods have become impractical, and many manufacturers have begun distributing their software products on CD-ROM disks.
As a result of the larger sized computer programs and the concomitant increasing complexity of the programs, the time required for installation of many programs has significantly increased, sometimes requiring an hour, or more, for a single program installation. One of the reasons that software installation consumes so much time is because virtually every bit of information in the program must be transferred from the delivery medium to an operating disk within the computer to which it is installed. Some software products can be installed using parallel information transfer, but others can be effected only by serial transfer techniques, one bit at a time. This is particularly time consuming, especially with some of the larger program products of the type mentioned above. This is especially true, for example, in Ethernet, and other serial network type installations.
In many distributed computer network environments, computer systems are configured in client-server arrangements, in which the present invention has particular utility. Typically, the server computer has a directory hierarchy that is often inflexible with regard to the client computers served by the server. For example, in most UNIX (UNIX is a trademark licensed by X/Open Company Ltd.) based operating systems, typically software products or applications must be installed without crossing the root/usr directory boundary, since /usr is a shared partition. This rigid approach has resulted in the construction of various rules by the operating system manufacturers that further complicates software installation onto server computer systems and which requires more time in effecting the proper application software installation process.
More particularly, in client-server arrangements, the server computer is provided with directories that contain certain information about each of the client computers that is served by the server. Typically, a server may have a number of disks, or disk partitions, which contain a required file system and client information to enable any particular client to perform specified client functions provided by the server. (The term "file system" is used herein to denote the logical file system seen and manipulated by a user.)
More particularly, for example, in a UNIX operating system, a server may provide a file system with portions that are shared by more than one client, portions that are unique to each client, and portions that are not modifiable or accessible by any client. Other operating systems may be similarly constructed. Typically, for example, a UNIX file system on a server includes for each client at least a root directory (/), a system characterization directory (/etc), and a user applications directory (/usr) . In addition, an operating system core directory called kernel (/kernel), and other supporting directories are also typically provided, as is known in the art.
The /etc directory generally contains all of the information that characterizes the client computer that is associated with that particular /etc directory. The /etc directory may contain, for example, all of the characterization files that may be associated with a particular software application to be run by the particular client computer. The /etc file may also contain, for instance, a file specifying other client computers with which the client may communicate, passwords for the client's particular applications, boot specifications for the client, and so on.
The /usr directory may contain a collection of subdirectories, including a subdirectory entitled /usr/bin, containing UNIX commands not contained in the /bin subdirectory of the root directory, a subdirectory called /usr/lib, containing most of the remaining UNIX information, and others. Typically, the /usr directory and many of its subdirectories can not be changed or written to by any client due to the fact that it is shared in common by several clients.
In a client-server arrangement where, for example, a large number of clients are connected to a server, the server must provide identification and characterization information for each client that is individualized for each particular client, but must additionally provide access among all of the clients to the information that is common to all of the clients, such as the data in /usr. It can therefore be seen that the job of maintaining the file system for the server and all of its clients can be a challenging and time consuming task.
The most common method for providing server-based file systems to clients is through the use of "Network File System," (hereinafter referred to as NFS). Developed in the mid-1980's by Sun Microsystems, Inc., NFS permits a computer (called a client) to gain access to a file system located on a different computer (called a server) using a local area network, such as Ethernet. Because of the functionality provided by NFS, the client gains access to the file system of the server as though it were a local file system of the client. To the client using NFS, the remote file system appears to be local. The client may, in fact, have no local disk at all; that is, it may be "diskless." Nonetheless, even such a diskless computer may demonstrate full functionality using only the file systems of the server.
Still more particularly, the network file system of the client has an interface to a file system facility (possibly a UNIX file system, UFS) within the server itself. Thus, the client has the illusion that it has a disk, when in fact it may not. The illusory disk appears to contain the root (/) and /usr directories. The area within the server that contains the disk or disk region that appears to be the disk containing data unique to the client is referred to by some unique name, for example, client.sub.-- 1. Other client disks (or disk portions) within the server, for example, client.sub.-- 2, client.sub.-- 3, . . . may be similarly configured.
The disk area within the server, sometimes referred to as the "root area", therefore, contains a number of client regions, each containing individualized root (/), /etc, and /kernel files for each respective client served by the server. The clients, however, all share certain common facilities, with access to particular applications being defined, for example, in the /usr directory. Thus, in general, except for the root area, the directories associated in the server with each client computer are shared and identical, and, therefore, are unmodifiable by the clients. The illusion, therefore, from the client computer perspective is that it has a disk with all of the file systems immediately available on it. It can be observed that among the root (/), /usr, and other characterizing files among the various clients served by the server, only a fraction of the overall information among the different respective files is different. Because of this, certain directories (typically /usr among them) are not duplicated from client to client. There is usually only one /usr directory on the server for use by the clients. This "shared area" (one of perhaps several) is used by all clients in common.
One of the problems of this type system is that the time required to install each client's software is relatively large. If a large number of clients are connected to a single server, the time is multiplied by the number of clients that are served, and may become extremely large. Another problem is that from the view point of the server, it presently is not possible to determine the software made available to each client via the shared areas to which each particular client may be privy.
Additionally, to upgrade any particular client may also take an inordinate amount of time. Typically, for example, an upgrade of a software product entails identifying files that require change, renaming the files to enable a restoration if the upgrade is not successful, then writing an upgraded file in its place. Every file in the file system must be analyzed in order to determine if it is to be upgraded. Thus, typically, an upgrade can take many hours to accomplish, especially with the large files in software products, as mentioned above. Like original software installation, an upgrade installation must also be repeated across each client's root area, still further multiplying the amount of time necessary for the upgrade. Sometimes, in fact, with the installation and removal functions of a upgrade, the process of upgrading a particular software product may even take longer than the original installation of the original software product.
In addition to the time requirements of an upgrade, upgrading software products may be risky. If any particular software in the product is changed, but not detected by a software upgrade, the upgraded system may not operate at all upon completion. In that event, since the upgraded portions of the software must be removed and the original portions reinstalled, if some portion of the original software has been changed, but is unrecorded, the restoration of the original version may not be possible. In such case, typically, the original version must be totally reinstalled and the changed file identified, for example, by reviewing the last backup of the system. In many instances, if an upgrade is attempted, but for some reason is not acceptable to the client, downgrade data to return to the original version are usually not available.
Many software applications maintain a database that contains a list of contents of the particular application. Oftentimes, however, the database becomes damaged, for example, by a power failure, system hardware failure, or other reason, and the access to the various stored data becomes difficult, if not impossible. At that point, again, the original software products must be totally reinstalled.
Often, software application vendors provide "patches" to correct bugs or to modify the software in certain ways. Not only are such patches frequently slow and inefficient, but they may be difficult to perform, and also frequently require large amounts of time to execute. In client-server installations, it is sometimes desired to apply a patch to one particular client, but not another. If the patch must be applied to both the root and shared /usr areas, the other clients see only part of the patch, thereby rendering the patched application useless to the non-patched clients. Moreover, once a patch has been applied incorrectly, often the patch cannot be undone, again resulting in a requirement that the software package be entirely reinstalled. Like upgrades, patches may take as long to install as the original software application.
Still another problem that is encountered in client-server work environments is that although certain clients would like to make various changes in some shared configuration files, they cannot be allowed to do so, since such changes might affect the operation of other clients that are using the shares software on the same server.
What is needed, therefore, is a method for installing software applications or data for use by clients in a stand alone or network environment that can be performed rapidly, can be easily patched, modified, or uninstalled, and that allows individual clients access, without affecting other clients use of the software.